Chip 1996 November

home *** CD-ROM | disk | FTP | other *** search

/ Chip 1996 November / Chip 11-96.iso / workshop / howto / firewall < prev next >

Wrap

Text File | 1996-05-25 | 29.4 KB | 778 lines

Firewalling and Proxy Server HOWTO David Rudder, drig@execpc.com v0.2, 17 July 1995 This document is designed to teach the basics of setting up a firewall on a Linux based PC. Also covered is the installation and use of Proxy Servers to allow greater access to the Internet from behind a firewall. 1. Introduction Firewalls have gained great fame recently as the ultimate in Internet Security. Like most things that gain fame, with that fame has come misunderstanding. This HOWTO will go over the basics of what a firewall is, how to set one up, what proxy servers are, how to set up proxy servers, and the applications of this technology outside of the security realm. 1.1. Feedback Any feedback is very welcome. I am particularly looking for feedback from people who use Macintosh computers, as the information I have on them is scanty. PLEASE PLEASE PLEASE REPORT ANY INACCURACIES IN THIS PAPER!!! I am human, and prone to making mistakes. If you find any, fixing them is of my highest interest. I will try to answer all e- mail, but I am busy, so don't get insulted if I don't. My email address is drig@execpc.com. 1.2. Disclaimer This document is meant as an introduction to how Firewalls and Proxy Servers work. I am not, not do I pretend to be, a security expert. I am just some guy who has read to much and likes computers more than people. I AM NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THIS DOCUMENT. Please, I am writing this to help get people acquainted with this subject, and I am not ready to stake my life on the accuracy of what is in here. 1.3. Copyright Unless otherwise stated, Linux HOWTO documents are copyrighted by their respective authors. Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions. All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below. In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, and would like to be notified of any plans to redistribute the HOWTOs. If you have any questions, please contact David Rudder <drig@execpc.com>. 1.4. My Reasons for Writing This There were a lot of discussions on comp.os.linux.* over the past year or so asking for Firewalling help. It seemed as if no one was going to answer these. I assumed that the reason was that no one knew how. So, I set aside some time to play with Firewalling and teach myself it. This document is in response to those requests. 1.5. TODO o Learn how to do this on a Macintosh o Learn different Windows TCP/IP packages o Find a good UDP proxy server that works with Linux 1.6. Further Readings o The Documentation for the TIS Firewall Toolkit o The NET-2 HOWTO o The PPP HOWTO o The Ethernet HOWTO o The Multiple Ethernet Mini HOWTO o Networking with Linux o TCP/IP Network Administrator's Guide by O'Reilly and Associates The Firewall Toolkit by TIS has a collection of the best documentation I have found on firewalls and related constructs. For more on the Firewall Toolkit, look for the section Firewalling Software. 2. Understanding Firewalls A Firewall is a term used for a part of a car. In cars, Firewalls are physical objects that separate the engine block from the passenger compartment. They are meant to protect the passenger in case the car explodes. A Firewall in computers is a logical device that protects a private network from the public part. How they work is: 1. You take a computer that has routing capabilities (such as a linux box) 2. Put in 2 interfaces (ie Serial ports, Ethernet, Token Ring, etc) 3. Turn off IP forwarding 4. Connect the internet to one interface 5. Connect the protected network to the other interface Now, you have two distinct networks, which share a computer. The firewall computer, from now on named "firewall", can reach both the protected network and the internet. The protected network can not reach the internet, and the internet can not reach the protected network. For someone to reach the internet from inside the protected network, one must telnet to firewall, and use the internet from there. Accordingly, in order to get into the protected network, one must go through the firewall first. This provides excellent security against attacks from the internet. If someone wants to make a concerted attack against the protected network, they must go through the firewall first, making it a two- step, and thus much harder, attack. If someone wants to attack the protected network via a more common method, such as mail bombing, or the infamous "Internet Worm", they will not be able to reach the protected network. This makes for excellent protection. 2.1. Drawbacks with Firewalls The biggest problem with firewalls is that they greatly inhibit the access to the internet from the inside. Basically, they reduce the usage of the internet to that which one would have via a dial-up shell account. Having to login to firewall and then do all internet access is a severe restriction. Programs like Netscape, which require a direct internet connection, will not work from behind a firewall. The answer to these problems is having a Proxy Server. 2.2. Proxy Servers Proxy servers are constructs that allow direct internet access from behind a firewall. How they work is they open a socket on the server, and allow communication via that socket to the internet. For example, if my computer, drig is inside the protected network, and I want to browse the Web using Netscape, I would set up a proxy server on firewall. The proxy server would be configured to allow requests from my computer, trying for port 80, to connect to its port 1080, and it would then redirect all requests to the proper places. Anyone that has used TIA or TERM has seen this concept before. Using these two programs, you can redirect a port. A friend had TIA setup to allow anyone using 192.251.139.21 port 4024 to connect to his Web Server. The proxy server works like this, but backwards. To connect to anyone else's port 80, you must use port 1080 (or whichever port you set it for). The great thing about proxy servers is that they are completely secure, when configured correctly. They will not allow someone in through them. 3. Setting This All Up 3.1. Hardware requirements For our example, the computer is a 486-DX66, 8 megs of memory, 500 megs Linux partition, with a PPP connection to it internet provider over a 14.4 modem. This setup is your basic Linux box. To make it a firewall, we add one NE2000 Ethernet card. It is then connected to 3 PC's running Windows 3.1 with Trumpet Winsock and 2 Suns running SunOS 4.1. This setup was chosen because it is a fairly common and they are both platforms that I am familiar with. I imagine much of the same stuff that I am talking about here is doable with Macs, but since I don't use Macs frequently enough, I don't really know. 3.2. Setting up the Software So, you have one Linux box connected to the net via a 14.4 PPP line. You then have a Ethernet network connected to the Linux box and all the other computers. First, you must recompile the Linux kernel with the appropriate options. At this point, I would look at the Kernel HOWTO, the Ethernet HOWTO, and the NET-2 HOWTO. Then, do a "make config": 1. Turn on Networking Support 2. Turn on TCP/IP Networking 3. Turn off IP Forwarding (CONFIG_IP_FORWARD). 4. Turn on IP Firewalling 5. Probably turn on IP accounting. Seems prudent since we are setting up a security measure 6. Turn on Networking Device Support 7. We turn on PPP and Ethernet support, but that depends on your interfaces Then, we recompile, reinstall the kernel and reboot. The interfaces should show up in the boot-up sequence, and we should be fine. If not, go over the other HOWTOs again until it is working. 3.3. Configuring the Network Addresses This is the real interesting part. Since we do not want the internet to have access, we do not need to use real addresses. One good C Class to use is 192.168.2.xxx, which was set aside as a dummy test domain. Thus, no one uses it, and it will not conflict with any requests for the outside. So, in this configuration, only one real IP address is needed. The others are free for the taking and will not affect the network at all. Assign the real IP to the serial port used for the PPP. Assign 192.168.2.1 to the Ethernet card on firewall. Assign all the other machines in the protected network some number in that domain. 3.4. Testing it out First, try to ping the internet from firewall. I used to use nic.ddn.mil as my test point. It's still a good test, but has proven to be less reliable than I had hoped. If it doesn't work at first, try pinging a couple other places that are not connected to your LAN. If this doesn't work, then your PPP is incorrectly setup. Reread the Net-2 HOWTO, and try again. Now, try pinging between hosts within the protected network. All the computers should be able to ping each other. If not, go over the NET-2 HOWTO again and work on the network some more. Then, every machine in the protected network should be able to ping firewall. If not, go back again. Remember, they should be able to ping 192.168.2.1, not the PPP address. Then, try to ping the PPP address of firewall from inside the protected network. If you can, then you have not turned off IP Forwarding and you will have to recompile the kernel. Having assigned the protected network the 192.168.2.1 domain means that no packets will be routed to this network anyway, but it is safer to have IP Forwarding turned off anyway. This leaves the control in your hands, not in the hands of your PPP provider. Finally, ping each machine within the protected network from firewall. By this time, there should be no problems. Now, you have your basic firewall setup. 3.5. Securing the Firewall The firewall is no good if it is left wide open to attacks. First, look at /etc/inetd.conf. This file is what is called a "super server". It runs a bunch of the server daemons as they are requested. Examples are: o Telnet o Talk o FTP o Daytime Turn off everything that is not needed. Definitely turn off netstat, systat, tftp, bootp, and finger. You might also want to turn off telnet, and only allow rlogin, or vica-versa. To turn a service off, merely put a # in front of it. Then, send a SIG-HUP to the process by typing kill -HUP <pid>, where pid is the process number of inetd. This will make inetd re-read its configuration file (inetd.conf) and restart. Test it out by telneting to port 15 on firewall, the netstat port. If you get an output of netstat, you have not restarted it correctly. 4. Firewalling Software 4.1. Available packages Strict firewalling does not need any software except the Linux kernel and the base networking packages (inetd, telnetd and telnet, ftpd and ftp). But, a firewall like this is extremely restrictive and not very useful. So, software packages have been made to make a firewall more useful. The one that I would like to examine in most detail is a package called "socks" which is a proxy server. But, there are two other programs that you might want to keep in mind. I would like to give you a short review of them now. 4.2. The TIS Firewall Toolkit TIS has put out a collection of programs designed to facilitate firewalling. The programs do basically the same thing as the Socks package, but with a different design strategy. Where Socks has one program that covers all Internet transactions, TIS has provided one program for each utility that wishes to use the firewall. To better contrast the two, lets take the example of World Wide Web and Telnet access. With Socks, you set up one configuration file and one daemon. Through this file and daemon, both Telnet and WWW are enabled, as well as any other service that you have not disabled. With the TIS toolkit, you set up one daemon for each WWW and Telnet, as well as configuration files for each. After you have done this, other Internet access is still prohibited until explicitly set up. If a daemon for a specific utility has not been provided (like talk), there is a "plug-in" daemon, but it is neither as flexible, nor as easy to set up, as the other tools. This might seem a minor difference, but it makes a major difference. Socks allows you to be sloppy. With a poorly set up Socks server, someone from the inside could gain more access to the Internet than was originally intended. With the TIS toolkit, the people on the inside have only the access the system administrator wants them to have. Socks is easier to set up, easier to compile and allows for greater flexibility. The TIS toolkit is more secure if you want to regulate the users inside the protected network. Both provide absolute protection from the outside. 4.3. TCP Wrapper TCP wrapper is not a firewalling utility, but it allows for many of the same effects. Using TCP wrapper, you can control who has access to your machine and to what services as well as keep logs of the connections. It does basic forgery detection also. TCP wrapper is not covered more extensively here because of a couple of reasons. o It is not a real firewall. o To use it, you have to be connected to the Internet, thus you have to have an IP address. o It only controls the machine it is installed on, and is thus not good for a network. Firewalls can protect every machine of every architecture. TCP wrapper won't work on Macintoshes and MS Windows machines. 4.4. Ipfw and Ipfw Admin 5. The Proxy Server 5.1. Setting up the Proxy Server The proxy server requires additional software. You can get this software from ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux- src.tgz. There is also an example config file in that directory called "socks-conf". Uncompress and untar the files into a directory on your system, and follow the instructions on how to make it. I had a couple problems in making it. Make sure that the Makefiles are correct. Some are, some are not. One important thing to note is that the proxy server needs to be added to /etc/inetd.conf. You must add a line: socks stream tcp nowait nobody /usr/local/etc/sockd sockd to tell the server to run when requested. 5.2. Configuring the Proxy Server The socks program needs two separate configuration files. One to tell the access allowed, and one to route the requests to the appropriate proxy server. The access file should be housed on the server. The routing file should be housed on every Un*x machine. The DOS and, presumably, Macintosh computers will do their own routing. 5.2.1. The Access File With socks4.2 Beta, the access file is called "sockd.conf". It should contain 2 lines, a permit and a deny line. Each line will have three entries: o The Identifier (permit/deny) o The IP address o The address modifier The identifier is either permit or deny. You should have both a permit and a deny line. The IP address holds a four byte address in typical IP dot notation. Ie 192.168.2.0. The address modifier is also a typical IP address four byte number. It works like a netmask. Envision this number to be 32 bits (1s or 0s). If the bit is a 1, the corresponding bit of the address that it is checking must match the corresponding bit in the IP address field. For instance, if the line is: permit 192.168.2.23 255.255.255.255 then, it will permit only the IP address that matches every bit in 192.168.2.23, eg, only 192.168.2.3. The line: permit 192.168.2.0 255.255.255.0 will permit every number within group 192.168.2.0 through 192.168.2.255, the whole C Class domain. One should not have the line: permit 192.168.2.0 0.0.0.0 as this will permit every address, regardless. So, first permit every address you want to permit, and then deny the rest. To allow everyone in the domain 192.168.2.xxx, the lines: permit 192.168.2.0 255.255.255.0 deny 0.0.0.0 0.0.0.0 will work nicely. Notice the first "0.0.0.0" in the deny line. With a modifier of 0.0.0.0, the IP address field does not matter. All 0's is the norm because it is easy to type. More than one entry of each is allowed. Specific users can also be granted or denied access. This is done via ident authentication. Not all systems support ident, including Trumpet Winsock, so I will not go into it here. The documentation with socks is quite adequate on this subject. 5.2.2. The Routing File The routing file in socks is poorly named "socks.conf". I say "poorly named" because it is so close to the name of the access file that it is easy to get the two confused. The routing file is there to tell the socks clients when to use socks and when not to. For instance, in our network, 192.168.2.3 will not need to use socks to talk with 192.168.2.1, firewall. It has a direct connection in via Ethernet. It defines 127.0.0.1, the loopback, automatically. Of course you do not need socks to talk to yourself. There are three entries: o deny o direct o sockd Deny tells socks when to reject a request. This entry has the same three fields as in sockd.conf, identifier, address and modifier. Generally, since this is also handled by sockd.conf, the access file, the modifier field is set to 0.0.0.0. If you want to preclude yourself from calling any place, you can do it here. The direct entry tells which addresses to not use socks for. These are all the addresses that can be reached without the proxy server. Again we have the three fields, identifier, address and modifier. Our example would have direct 192.168.2.0 255.255.255.0 Thus going direct for any on our protected network. The sockd entry tells the computer which host has the socks server daemon on it. The syntax is: sockd @=<serverlist> <IP address> <modifier> Notice the @= entry. This allows you to set the IP addresses of a list of proxy servers. In our example, we only use one proxy server. But, you can have many to allow a greater load and for redundancy in case of failure. The IP address and modifier fields work just like in the other examples. You specify which addresses go where through these. 5.2.3. DNS from behind a Firewall Setting up Domain Name service from behind a firewall is a relatively simple task. You need merely to set up the DNS on the firewalling machine. Then, set each machine behind the firewall to use this DNS. 5.3. Working With a Proxy Server 5.3.1. Unix To have your applications work with the proxy server, they need to be "sockified". You will need two different telnets, one for direct communication, one for communication via the proxy server. Socks comes with instructions on how to sockify a program, as well as a couple pre-sockified programs. If you use the sockified version to go somewhere direct, socks will automatically switch over to the direct version for you. Because of this, we want to rename all the programs on our protected network and replace them with the sockified programs. "Finger" becomes "finger.orig", "telnet" becomes "telnet.orig", etc. You must tell socks about each of these via the include/socks.h file. Certain programs will handle routing and sockifying itself. Netscape is one of these. You can use a proxy server under Netscape by entering the server's address (192.168.2.1 in our case) in the SOCKs field under Proxies. Each application will need at least a little messing with, regardless of how it handles a proxy server. 5.3.2. MS Windows with Trumpet Winsock Trumpet Winsock comes with built in proxy server capabilities. In the "setup" menu, enter the IP address of the server, and the addresses of all the computers reachable directly. Trumpet will then handle all outgoing packets. 5.4. Getting the Proxy Server to work with UDP Packets The socks package works only with TCP packets, not UDP. This makes it quite a bit less useful. Many useful programs, such as talk and Archie, use UDP. There is a package designed to be used as a proxy server for UDP packets called UDPrelay, by Tom Fitzgerald <fitz@wang.com>. Unfortunately, at the time of this writing, it is not compatible with Linux. 5.5. Drawbacks with Proxy Servers The proxy server is, above all, a security device. Using it to increase internet access with limited IP addresses will have many drawbacks. A proxy server will allow greater access from inside the protected network to the outside, but will keep the inside completely unaccessible from the outside. This means no servers, talk or Archie connections, or direct mailing to the inside computers. These drawbacks might seem slight, but think of it this way: o You have left a report you are doing on your computer inside a firewall protected network. You are at home, and decide that you would like to go over it. You can not. You can not reach your computer because it is behind the firewall. You try to log into firewall first, but since everyone has proxy server access, no one has set up an account for you on it. o Your daughter goes to college. You want to email her. You have some private things to talk about, and would rather have your mail sent directly to your machine. You trust your systems administrator completely, but still, this is private mail. o The inability to use UDP packets represents a big drawback with the proxy servers. I imagine UDP capabilities will be coming shortly. FTP causes another problem with a proxy server. When geting or doing an ls, the FTP server opens a socket on the client machine and sends the information through it. A proxy server will not allow this, so FTP doesn't particularly work. And, proxy servers run slow. Because of the greater overhead, almost any other means of getting this access will be faster. Basically, if you have the IP addresses, and you are not worried about security, do not use a firewall and/or proxy servers. If you do not have the IP addresses, but you are also not worried about security, you might also want to look into using an IP emulator, like Term, Slirp or TIA. Term is available from ftp://sunsite.unc.edu, Slirp is available from ftp://blitzen.canberra.edu.au/pub/slirp, and TIA is available from marketplace.com. These packages will run faster, allow better connections, and provide a greater level of access to the inside network from the internet. Proxy servers are good for those networks which have a lot of hosts that will want to connect to the internet on the fly, with one setup and little work after that. 6. Advanced Configurations There is one configuration I would like to go over before wrapping this document up. The one I have just outlined will probably suffice for most people. However, I think the next outline will show a more advanced configuration that can clear up some questions. If you have questions beyond what I have just covered, or are just interested in the versatility of proxy servers and firewalls, read on. 6.1. A large network with emphasis on security Say, for instance, you are the leader of the Milwaukee 23rd Discordian Cabal. You wish to network your site. You have 50 computers and a subnet of 32 (5 bits) IP numbers. You have various levels of access. You tell your disciples different things according to each level. Obviously, you would want to protect certain parts of the network from the disciples that are not in that level. Disclaimer: I am not a member of the Discordians. I do not know their terminology, nor do I really care. I am using them as an example only. Please send all flames to The levels are: 1. The external level. This is the level that gets shown to everybody. Basically, this is the ranting and raving about Eris, Goddess of Discord, and all the rest of the drivel. 2. Sage This is the level of people who have gotten beyond the external level. Here is where you tell them that discord and structure are really one, and that Eris is also Jehovah. 3. Adept Here is where the real plan is. In this level is stored all the information on how the Discordian Society is going to take over the world through a devious, yet humorous, plan involving Newt Gingrich, Wheaties Cereal, O.J. Simpson, and five hundred crystals, all erroneously marked "6.5 MHz". 6.1.1. The Network Setup The IP numbers are arranged as: o 1 number is 192.168.2.255, which is the broadcast address and is not usable. o 23 of the 32 IP addresses are allocated to 23 machines that will be accessible to the internet. o 1 extra IP goes to a linux box on that network o 1 extra goes to a different linux box on that network. o 2 IP #'s go to the router o 4 are left over, but given domain names paul, ringo, john, and george, just to confuse things a bit. o The protected networks both have the addresses 192.168.2.xxx Then, two separate networks are built, each in different rooms. They are routed via Infrared Ethernet so that they are completely invisible to the outside room. Luckily, infrared Ethernet works just like normal Ethernet (or so i think), so we can just think of them like normal. These networks are each connected to one of the linux boxes with an extra IP address. There is a file server connecting the two protected networks. This is because the plans for taking over the world involves some of the higher sages. The file server holds the address 192.168.2.17 for the sage network and 192.168.2.23 for the adept network. It has to have different IP addresses because it has to have different Ethernet cards. IP Forwarding on it is turned off. IP Forwarding on both Linux boxes is also turned off. The router will not forward packets destined for 192.168.2.xxx unless explicitly told to do so, so the internet will not be able to get in. The reason for turning off IP Forwarding here is so that packets from the sage network will not be able to reach the adept network, and vica versa. The NFS server can also be set to offer different files to the different networks. This can come in handy, and a little trickery with symbolic links can make it so that the common files can be shared with all. Using this setup and another Ethernet card can offer this one file server for all three networks. 6.1.2. The Proxy Setup Now, since all three levels want to be able to monitor the network for their own devious purposes, all three need to have net access. The external network is connected directly into the internet, so we don't have to mess with proxy servers here. The adept and sage networks are behind firewalls, so it is necessary to set up proxy servers here. Both networks will be setup very similarly. They both have the same IP addresses assigned to them. I will throw in a couple of parameters, just to make things more interesting though. 1. No one can use the file server for internet access. This exposes the file server to viruses and other nasty things, and it is rather important, so its off limits. 2. We will not allow Sage access to the World Wide Web. They are in training, and this kind of information retrieval power might prove to be damaging. So, the sockd.conf file on the sage linux box will have this line: deny 192.168.2.17 255.255.255.255 and on the adept machine: deny 192.168.2.23 255.255.255.255 And, the sage linux box will have this line deny 0.0.0.0 0.0.0.0 eq 80 This says to deny access to all machines trying to access the port equal (eq) to 80, the http port. This will still allow all other services, just deny Web access. Then, both files will have: permit 192.168.2.0 255.255.255.0 to allow all the computers on the 192.168.2.xxx network to use this proxy server except for those that have already been denied (ie. the file server and Web access from the sage network). The sage sockd.conf file will look like: deny 192.168.2.17 255.255.255.255 deny 0.0.0.0 0.0.0.0 eq 80 permit 192.168.2.0 255.255.255.0 and the adept file will look like: deny 192.168.2.23 255.255.255.255 permit 192.168.2.0 255.255.255.0 This should configure everything correctly. Each network is isolated accordingly, with the proper amount of interaction. Everyone should be happy. Now, look out for your 6.5 MHz crystals